Search Results: "Niko Tyni"

8 April 2012

Gregor Herrmann: RC bugs 2012/14

good news: it looks like more & more people are working on RC bugs & doing NMUs. here are my contributions from this week:

1 April 2012

Gregor Herrmann: RC bugs 2012/13

due to some new incoming RC bugs, this week was more devoted to fixing bugs in "our" (= the Debian Perl Group's) packages. here's the list:

15 January 2012

Gregor Herrmann: RC bugs 2012/02

while working on RC bugs, I noticed that some DDs sent patches to the BTS in the last weeks (yeah!) but did not upload the fixes in NMUs. short request: could you please either state the reason for not uploading, or just go ahead and dput/dupload the fixed packages?

& here's my list:

20 November 2011

Gregor Herrmann: RC bugs 2011/46

as expected this week was characterised by fixing bugs around the perl 5.14 transition. besides that I've also uploaded a couple of NMUs with patches kindly provided in the BTS by some tireless bug fixers.

23 May 2011

Gregor Herrmann: RC bugs 2011/11 - 2011/20

long time no post about my RC bug fixing activities. & indeed, I haven't been very active during the last weeks. here's a quick update; it includes two NMUs done for the perl 5.12 transition, the rest is just "normal" maintainance work (interesting to see how much stuff can break behind our backs ...). I still hope to find some more time in the future to look at other RC bugs; after all we want to have a not-too-long freeze for wheezy, don't we?

5 October 2008

Russ Allbery: podlators 2.2.0

While incorporating some of the podlators fixes into the Perl that will be released with lenny, Niko Tyni found more problems with the current implementation. I'd written the test suite to force the output encoding on the file handle used by Pod::Man and Pod::Text, but pod2man and pod2text weren't doing that, and hence the output wasn't properly encoded. I'm finding Perl's Unicode support very tricky, particularly if I want to support the PERL_UNICODE option that adds input and output encodings on all file handles. I can't use encode before output because PERL_UNICODE encoding layers will then double-encode. The approach taken in this release is to force the appropriate output encoding on the output file handle (possibly destroying caller state). This works, but it's ugly. Pod::Text had another problem. Its historic behavior is to copy the input encoding to the output, but doing that with properly-tagged UTF-8 POD input means printing out wide characters in the internal encoding, resulting in Perl warnings. This version now, in the absence of the utf8 option, forces the output encoding to match the input encoding if possible. This seems like the best compromise and matches its historic behavior. pod2text now supports a --utf8 option since it's now useful to force a different output encoding. I wanted to get something out to stop the bleeding, but there are a few problems with the current approach. As mentioned above, I'm forcing file handle encoding layers, which may destroy encoding layers created by the caller that were intentional. This implementation also depends on PerlIO support, which is an optional Perl feature and not always enabled. I think the right long-term approach is to probe for PerlIO support, and if present, use it to check the encoding layer on the output file handle. If PerlIO is not set, or if no encoding layer is present, I can safely use encode before output, which doesn't mess with the file handle state and is much cleaner. If PerlIO is present and an output encoding is set, just trust that output encoding (although if the utf8 option is set and the output encoding is something else, it may be a good idea to throw a warning). I'm not sure when I'll have time to implement this, though, since it will require another reworking of the code and more testing, and I'm behind on a number of other projects. In any event, the current version will work for most people in most cases. You can get it from the podlators distribution page.

21 September 2008

Frank Lichtenheld: Lintian 2.0.0~rc2 in experimental

For the impatient reader: New lintian in experimental, please test and give feedback. You will miss most changes though unless you read the rest of the post (Hint, Hint ;)) During the past week I've uploaded new lintian versions to experimental which we designated to be release candidates for 2.0.0. Code-wise the changes are not that much more intrusive than for many of our past releases, but they change the way lintian classifies tags in a fundamental way, thanks due to the hard work of Jord Polo in his Google Summer of Code project (mentored by Marc Brockschmidt). Lintian Tag Classification, old and new Previously lintian classified tags only in one dimension, in the categories "Info", "Warning", and "Error". While this worked reasonably well, the difference between the categories was not very well defined. The general idea was that everything violating a "must" in Debian Policy or endangering the building or usage of the package should be an "Error", i.e. something very similar to the definition of RC bugs (except that not all "must"s in Policy are deemed worthy of filing RC bugs). Some errors were downgraded to "Warning" or even "Info" though on the basis that their detection was too prone to false positives. Due to this it was a long existing desire to split the classification of tags into two dimensions, one for the impact/importance of the tag, and one for the certainty of its correct detection. This should make it easier for people to interpret and/or filter the output. At various points in the last few years people began to work on this but quickly gave up, usually overwhelmed by the sheer number of tags (728 in 2.0.0~rc2) to classify anew and to make sure that the old and new categorisation could exist side-by-side (because breaking backwards compatibility was not really feasible). Finally this year Jord Polo decided to tackle this task as a Google Summer of Code project, with great success. Tags are now classified in two dimensions "Severity" (with the possible values wishlist, minor, normal, important, serious, which are intentionally very close to the available severities in the Debian bug tracking system), and "Certainty" (possible values: wild-guess, possible, certain). A third classification by "Source" (i.e. Policy, Developers Reference, ...) is planned but not yet fully implemented. For backwards compatibility there is a mapping of these new classification to the old ones (which lead to a few reclassifications of tags). The default output of lintian is unchanged. The new output formats that support the classification are still experimental (see below). How to use it You can specify exactly which levels of Severity and Certainty you want to have displayed with the new --display-level (-L) option. Please see the manual page for the details, but to give you an idea, the default behaviour (i.e. "show warnings and errors" in the "old" vocabulary) is equivalent to specifying 
-L ">=important" -L "+>=normal/possible" -L +minor/certain
And to get a report with only severe tags we're very certain of, you could use 
-L ">=important/certain"
which will only display tags that have severity "important" or "serious" and a certainty of certain. There is also the (intentionally undocumented) option --exp-output which allows you to play with some experiments we're doing with the output format. --exp-output format=letterqualifier will give you an output very similar to the "classic" one, but with additional information about severity and certainty. --exp-output format=colons gives you a colon-separated format which includes all the possible information lintian currently has available during tag output and which should be easily machine-consumable. Note that these formats are experimental and might be changed at any point without notice. If you're interested in using alternative formats for lintian output, please join the mailing list and talk to us about it. Etc. Other changes include the usual share of bug fixes and of course: New tags Credits This lintian release is brought to you by (sorted by number of changesets):

14 September 2008

Russ Allbery: podlators 2.1.3

The primary change in this version is some sorting-out of the Unicode support. Thank you very much to H. Merijn Brand and Juerd Waalboer for their patient explanations of the Perl core test suite failures and how Perl Unicode support is supposed to work. As of this version, Unicode support in pod2man and Pod::Man will not work properly unless the POD input properly declares =encoding utf-8. This is required, and always has been required, by the POD specification. Without this setting, some Unicode settings of Perl will result in doubled encoding. Proper encoding is now tested in the test suite. This version also adds a --stderr option to pod2man and pod2text and a corresponding setting to Pod::Text and Pod::Man which sends errors in the POD to stderr instead of to a POD ERRORS section in the generated file. This may be preferrable, since the POD errors aren't of interest to the end-user and errors may be more visible during the build. There are some additional fixes to the documentation and the spelling checks, thanks primarily to Niko Tyni. You can get the latest version from the podlators distribution page.

18 April 2008

Gregor Herrmann: surprise

when I woke up today (after sleeping in for the first time with my new roll-top in front of my bedroom window) I was surprised & confused by a couple of "congratulations!" messages in my irc away-log. it took me a bit of time & coffee (& looking into my mailbox) to begin to realize that my Debian account had indeed been created while I was asleep. — in fact I guess I still haven't completely realized my new status as Debian Developer.

as others I'd like to follow the good tradition of taking the opportunity to thank some of the people who helped me to get there: some final thoughts about the NM process from my point of view: & now it's time first to celebrate & then to try to fully grasp my new rights & responsibilities.

14 July 2007

Gunnar Wolf: On collaborative maintenance

Following Zack's and Lucas' posts regarding group maintenance of packages: Do I have to AOL with you guys? Yes, I also agree with Zack's both 1 and 2. And I also want to share the bit of experience we have got in this regard in the pkg-perl group. In our case, group maintainership has often saved our collective butts. We have also debated somewhat which way should our packages' maintainership be handled. In the end, our packages' maintainer will (most usually) be the pkg-perl group itself, subscribed through an alias that reaches all of us. Then, every group member that feels identified with the package lists himself as an uploader (note that this does not necessarily have a relation with the last uploads, at least not as strongly as in what the KDE and Gnome groups do, according to Lucas' post - it's closer to the pkg-ruby-extras handling). Of course, there are some packages which I have NMUed in the group's pool - packages I prefer not to have listed in my maintainer page, as I don't usually care too much about them, but I happened to be able to fix a bug with them.
Now, what about the roles of the different group members? Each of us has some skills that make him better for part of the task - i.e., we have an amazingly knowledgeable member, Niko Tyni. He just fixes all the bugs that baffle us. Honest, my best kudos to Niko, he is a good part of our team's success. And then, we have hard-working people as Gregor Hermann, who not only fixes also nice amounts of bugs, but also writes and runs general QA tests throughout our over 300 modules. Neither of them is a DD yet. And of course, many other hard-working folks. Some of us are DDs and try to upload promptly - and, of course, also try fixing bugs. So far, we are in good shape, and we tend not to lag too much. I have taken some vacation periods (both announced and unannounced - sorry :) ), but to my surprise and amazement, my packages tend not to be buggy - Why? Because there is a real team looking after them, and in the end, we keep an eye on each other.
For the pkg-perl group, group maintenance has really worked. We collectively maintain more packages than it would be reasonable for all of us added together as individuals, and they are in a better shape. There are several things we can make better, and we do try to address them - it is not yet heaven, but... :) I'll elaborate later, when I finish a text I'm preparing for presenting at YAPC (it's not that long, of course - During Debconf, I showed advances of it to several people... I just have left it aside). Right now... Well, I have 3hr of sleep left before we leave for a daytrip to the beautiful (but hot and humid!) Veracruz Huasteca. See you on Sunday/Monday!

Next.

Previous.